(1) Field of the Invention
This invention is directed to the field of data processing, and more particularly, to a novel asynchronous bidirectional network interface enabling seamless concurrent processing in a distributed heterogeneous multiprocessor system.
(2) Description of the Prior Art
Distributed computer systems exist in one of three principal architecture conformance types, namely, tightly-coupled multiprocessing systems, moderately-coupled multiprocessing systems, and loosely-coupled multiprocessing systems. The tightly-coupled distributed multiprocessing architecture conformance type is constituted by plural processors connected by either a memory bus or a backplane by which memory is globally shared; the moderately-coupled type is constituted by plural processors interconnected either by a backplane or a single-segment LAN with no global memory and where a standard store-and-forward information transfer mechanism may be employed, while the loosely-coupled distributed multiprocessor architecture conformance type is constituted by plural processors coupled by multisegmented bridged LAN's (Local Area Networks including the transmission line thereof) and full WAN's (Wide Area Networks including the transmission line thereof) with a store-and-forward information transfer mechanism. Local memory may be provided to any processor of any of the multiprocessors of any of the three types of distributed systems. Typical backplanes for the tightly-coupled type advantageously may be the Futurebus+, and the Scalable Coherent Interface (SCI), and typical network standards and protocols for the moderately-coupled and loosely-coupled types may advantageously be the OSI Reference Model, TCP/IP, DECnet and SAFENET networks. Typical processors may advantageously be the MilVAX, MIPS R3000, Intel 80486, Motorola 68030, AMD 29000 and the Intel 88000, among others.
In order to utilize the full processing potential of any one of the distributed multiprocessing architecture conformance types, provision must be made to accommodate heterogeneous machines, namely, machines that may differ in data representation, instruction sets and/or architecture, among other things. For the tightly-coupled multiprocessor systems, where all of the processors have access to global memory attached to the common backplane or "bus", and where it is possible for all of the processors to share data by placing it in a mutually agreed upon address in global memory, heterogeneous multiple processor configurations introduce a number of complications. Whenever the processors are not alike, it becomes difficult to develop a compiler, such as an Ada compiler, and supporting runtimes across the entire suite of processors. In fact, there are a limited number of compiler vendors which produce a single compiler that targets a number of different processors. In those cases where a single compiler does target a number of different processors, the runtimes for each targeted processor are unique and usually do not incorporate the necessary mechanisms to interoperate such as support for heterogeneous cross-processor rendezvous. The problem of data representation at the machine level further complicates matters. One cannot simply share global data in commonly addressable memory without consideration of the cooperating target processors. Byte ordering between processors, for example, may differ; for instance, the VAX is a "little endian" (i.e., 0 byte being low order) processor while the other above-named exemplary processors are configured as "big endian" (i.e., 0 byte being high order) processors. If the intent is to have data shared in commonly addressable memory, the data producing processor, or the data consuming processor, or both, would have the responsibility of converting the data. Mechanisms such as the SUN external Data Representation (XDR), ISO's Abstract Syntax Notation 1 (ASN.1) or a unique conversion process could be used to convert the data from one processor's representation to the other processor's representation, or to a mutually agreed upon neutral representation. This, however, requires shadowing the global data with a similar data structure in the agreed upon representation, undesirably multiplying the memory requirement for sharing data by the number of processors requiring different representations. Another disadvantage would result from an effort to make all of these presentation issues invisible, which would require extensive modification to the runtime, such as an Ada runtime. And along with the invisibility would come questions from the system's designer of what effect the associated overhead would have on performance. When building a large embedded distributed system, the system designer does not want to consume time developing or modifying the compiler and/or runtime. Rather, it is the desire of the system designer to implement the application without distractions.
Moderately-coupled systems, like loosely-coupled systems, do not have global memory, so that mechanisms need be employed to share data and synchronize actions through communications protocols over the backplane or single segment LAN. These mechanisms are similar to those that would be necessary on loosely-coupled systems. For the loosely-coupled systems (and moderately-coupled systems) where the processors neither share global memory nor a single interconnect medium (i.e. a common backplane, bus or single segment LAN) but employ store-and-forward mechanisms to share data and to synchronize actions that are implemented through communications protocols, such as the SAFENET1 and SAFENET2 networking standards to be used in future Navy systems, the complications introduced by heterogeneous processors are such as to require the design, development and modification of a compiler, capable of supporting multiple backends and runtime systems which target each of the heterogeneous processors. For each processor of the heterogeneous processors, runtime environments would have to be developed/modified to support the level of desired distribution, which restrictions on the level of distribution would have a large effect on the resulting runtime overhead, since greater flexibility would result in a larger runtime overhead and size. Further, mechanisms within the runtime would be required to support memory management, time management, tasks and exceptions. Other mechanisms would also be needed to support processor interrupts, I/O, predefined packages, generic units, and, among other things, compiler/processor independent/dependent attributes.
There is thus a need to provide a mechanism other than a single compiler capable of supporting plural heterogeneous processors enabling concurrent processing for distributed systems configured in any one of the tightly-coupled, moderately-coupled and loosely-coupled hardware architecture conformance types.